<html>
<head><meta charset="utf-8"><title>lifetimes · general · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/index.html">general</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html">lifetimes</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="214012377"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214012377" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Haris Muzaffar <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214012377">(Oct 21 2020 at 06:32)</a>:</h4>
<p>I read about lifetimes in Rust, i know how to declare lifetimes but i still don't understand why Rust need the programmer's intervention to declare a lifetime. Consider this struct that holds a reference to a string slice</p>
<div class="codehilite"><pre><span></span><code>struct Test&lt;&#39;a&gt; {
    test: &amp;&#39;a str
}
</code></pre></div>


<p>All this is doing is declaring a lifetime, which in this case we called a, and saying that the string slice that any instances of this struct may have MUST live as long as a does</p>
<p>My question:<br>
Why doesn't enforce this by default? What is an example where we create an instance of this struct that should not compile(logically)?</p>



<a name="214014012"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214014012" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214014012">(Oct 21 2020 at 06:59)</a>:</h4>
<p>something like this?</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">fn</span> <span class="nf">foo</span><span class="p">()</span><span class="w"> </span>-&gt; <span class="nc">Test</span><span class="o">&lt;'</span><span class="nb">static</span><span class="o">&gt;</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="n">Test</span><span class="w"> </span><span class="p">{</span><span class="n">test</span>: <span class="kp">&amp;</span><span class="nb">String</span>::<span class="n">new</span><span class="p">()}</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>



<a name="214014577"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214014577" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214014577">(Oct 21 2020 at 07:07)</a>:</h4>
<p>less trivially:</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">fn</span> <span class="nf">foo</span><span class="o">&lt;'</span><span class="na">a</span><span class="p">,</span><span class="w"> </span><span class="o">'</span><span class="na">b</span><span class="o">&gt;</span><span class="p">(</span><span class="n">test</span>: <span class="kp">&amp;</span><span class="o">'</span><span class="na">a</span> <span class="nc">mut</span><span class="w"> </span><span class="n">Test</span><span class="o">&lt;'</span><span class="na">a</span><span class="o">&gt;</span><span class="p">,</span><span class="w"> </span><span class="n">s</span>: <span class="kp">&amp;</span><span class="o">'</span><span class="na">b</span> <span class="kt">str</span><span class="p">)</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="n">test</span><span class="p">.</span><span class="n">test</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">s</span><span class="p">;</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>

<p>or</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">fn</span> <span class="nf">foo</span><span class="p">(</span><span class="n">b</span>: <span class="kt">bool</span><span class="p">)</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="kd">let</span><span class="w"> </span><span class="n">x</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="k">if</span><span class="w"> </span><span class="n">b</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">        </span><span class="n">Test</span><span class="w"> </span><span class="p">{</span><span class="n">test</span>: <span class="kp">&amp;</span><span class="nc">format</span><span class="o">!</span><span class="p">(</span><span class="s">"2 + 2 = {}"</span><span class="p">,</span><span class="w"> </span><span class="mi">2</span><span class="w"> </span><span class="o">+</span><span class="w"> </span><span class="mi">2</span><span class="p">)}</span><span class="w"></span>
<span class="w">    </span><span class="p">}</span><span class="w"> </span><span class="k">else</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">        </span><span class="n">Test</span><span class="w"> </span><span class="p">{</span><span class="n">test</span>: <span class="kp">&amp;</span><span class="nc">format</span><span class="o">!</span><span class="p">(</span><span class="s">"hello {}"</span><span class="p">,</span><span class="w"> </span><span class="s">"haris"</span><span class="p">)}</span><span class="w"></span>
<span class="w">    </span><span class="p">};</span><span class="w"></span>
<span class="w">    </span><span class="n">println</span><span class="o">!</span><span class="p">(</span><span class="s">"{}"</span><span class="p">,</span><span class="w"> </span><span class="n">x</span><span class="p">.</span><span class="n">test</span><span class="p">)</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>



<a name="214014838"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214014838" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214014838">(Oct 21 2020 at 07:11)</a>:</h4>
<p>It's probably possible to infer lifetimes globally in rust, but it has the same drawbacks as full program type inference: it is very nonlocal and would be hard to predict</p>



<a name="214014944"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214014944" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214014944">(Oct 21 2020 at 07:12)</a>:</h4>
<p>in fact, some more advanced uses of lifetime bounds e.g. in function types might not even be expressible generically in a way that admits a principal type for full program lifetime inference</p>



<a name="214023751"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214023751" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214023751">(Oct 21 2020 at 08:52)</a>:</h4>
<p>There are cases where the lifetime has to be limited over what it could theoretically be to prevent unsoundness. For example with rental and owning_ref.</p>



<a name="214024045"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214024045" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214024045">(Oct 21 2020 at 08:55)</a>:</h4>
<p>Yeah, but in those cases the compiler can't help anyway and the crate is doing unsafe shenanigans to make things work</p>



<a name="214024175"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214024175" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214024175">(Oct 21 2020 at 08:56)</a>:</h4>
<p>I was thinking specifically about global inference for <em>safe</em> code</p>



<a name="214071136"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214071136" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214071136">(Oct 21 2020 at 15:54)</a>:</h4>
<p>Well, half the point with lifetimes is so that you <em>can</em> write unsafe code that is sound.</p>



<a name="214071864"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214071864" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> isHavvy <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214071864">(Oct 21 2020 at 15:58)</a>:</h4>
<p>Rust's type system purposely avoids doing global reasoning because that's hard for both humans and algorithms to determine.</p>
<p>And lifetimes are there so you can write safe code with references. It's maintaining the reference's invariants in the compiler. It's useful for writing unsafe code like anything else that enforces invariants, but it's definitely not the main reason for it.</p>



<a name="214072158"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214072158" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214072158">(Oct 21 2020 at 16:00)</a>:</h4>
<p>Oh yes, I am just saying unsafe code needs lifetimes for similar reasons rustc needs lifetime, ne? To define bounds and maintain invariants, programmatically or manually. An unspecified lifetime means that the lifetime is unbounded, which means that it is infinite in time, which means an eternity of suffering for the programmer. :D</p>



<a name="214073175"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214073175" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214073175">(Oct 21 2020 at 16:06)</a>:</h4>
<p>There's plenty of languages that have safe code with references <em>without</em> explicit lifetimes, they're called "managed memory" languages. But the price is paid in the workings of the GC being completely obscured from the programmer and also incurring overhead during runtime.</p>



<a name="214073475"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214073475" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Pankaj Ratan Lal <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214073475">(Oct 21 2020 at 16:07)</a>:</h4>
<p>On a related note, we were discussing this today. The question was related to the example of longest string in rust book. The first version in listing 10-21 doesn't compile, and then the one with annotations, 10-22 compiles. The question was that can't rust look at the implementation and auto infer the annotations instead of going by the three elision rules stated later.<br>
My answer to this was - and I want to know if I am right in what I am thinking - A compiler would not like to infer the declaration by looking at the implementation. It would like to make sure that the declaration is complete in itself. Declaration is the contract and would stay like that between caller and callee. What I could not answer with this theory was that rust does infer many things (like types) by doing a look ahead on the code and then enforcing the type if wrongly used. Why doesn't it then look at the implementation and do the best possible thing for lifetimes.</p>



<a name="214074003"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214074003" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> lcnr <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214074003">(Oct 21 2020 at 16:11)</a>:</h4>
<blockquote>
<p>What I could not answer with this theory was that rust does infer many things (like types) by doing a look ahead on the code and then enforcing the type if wrongly used. Why doesn't it then look at the implementation and do the best possible thing for lifetimes.</p>
</blockquote>
<p>It already does this quite a lot though, lifetimes inside of function bodies are automatically inferred.</p>



<a name="214074187"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214074187" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214074187">(Oct 21 2020 at 16:12)</a>:</h4>
<p>The section: <a href="https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html#generic-lifetimes-in-functions">https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html#generic-lifetimes-in-functions</a> </p>
<p>Type inference simply fails past a certain amount of lookup, where enough uncertainty is introduced.<br>
Here, it is simple.<br>
The uncertainty is between two parameters which are similar but different.<br>
It does not automatically know which it will return.</p>



<a name="214074304"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214074304" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214074304">(Oct 21 2020 at 16:13)</a>:</h4>
<p>This is fully explained in the book:</p>
<blockquote>
<p>When we’re defining this function, we don’t know the concrete values that will be passed into this function, so we don’t know whether the if case or the else case will execute. We also don’t know the concrete lifetimes of the references that will be passed in, so we can’t look at the scopes as we did in Listings 10-18 and 10-19 to determine whether the reference we return will always be valid. The borrow checker can’t determine this either, because it doesn’t know how the lifetimes of x and y relate to the lifetime of the return value. To fix this error, we’ll add generic lifetime parameters that define the relationship between the references so the borrow checker can perform its analysis.</p>
</blockquote>



<a name="214075279"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214075279" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Pankaj Ratan Lal <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214075279">(Oct 21 2020 at 16:19)</a>:</h4>
<p>I get the part that it does not know automatically, and so the suggestion to programmer is to put the lifetime explicitly and in this case what works is putting a <em>'a</em> on the inputs and outputs. <br>
However, for this simple example at least, isn't it obvious that compiler can do the same thing looking at implementation. Once it does so, the only part remaining is on the caller side. That can well result in compile errors if those guarantees (that we asked programmer to put, but as per my contention, compiler can take such safe decision by looking at implementation) are not met.</p>
<p>So in essence, I am suggesting the expansion of elision rules, by looking at implementation. Programmers can always over-ride those by doing something different with lifetime annotations on function declaration if they want.</p>



<a name="214075712"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214075712" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214075712">(Oct 21 2020 at 16:21)</a>:</h4>
<p>The problem is that it would break in essentially any more non-trivial version, so while what you describe is technically possible, there is not that much point to making it easier on you at that juncture.</p>



<a name="214075839"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214075839" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oliver <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214075839">(Oct 21 2020 at 16:22)</a>:</h4>
<p><span class="user-mention silent" data-user-id="315436">Pankaj Ratan Lal</span> <a href="#narrow/stream/122651-general/topic/lifetimes/near/214073475">said</a>:</p>
<blockquote>
<p>A compiler would not like to infer the declaration by looking at the implementation.... Why doesn't it then look at the implementation and do the best possible thing for lifetimes.</p>
</blockquote>
<p>Could you clarify? If the compiler would not like to do this isn't the question <br>
rather of extracting the eliding of Types and disabling some of the lookahead?</p>



<a name="214076710"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214076710" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214076710">(Oct 21 2020 at 16:27)</a>:</h4>
<p>So yes, we could add more to rustc to simplify away every example like this, but at some point that makes it so that your first engagement with lifetimes is a much steeper cliff-drop where you don't know what to do at all because you are in some snarled nest that our hypothetically maximally empowered rustc cannot see through, instead of having a comparatively simple annotation.</p>
<p>And it would probably be a lot of work in order to do that, only to get a worse UX. <span aria-label="sweat smile" class="emoji emoji-1f605" role="img" title="sweat smile">:sweat_smile:</span></p>



<a name="214077203"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214077203" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oliver <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214077203">(Oct 21 2020 at 16:30)</a>:</h4>
<p>I think it was always a matter of time before paradigms become well<br>
defined in a way that they are usable to most people most of the time</p>



<a name="214077502"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214077502" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214077502">(Oct 21 2020 at 16:33)</a>:</h4>
<p>Right, the languages that come after Rust can make different choices because now "do something like Rust does it" is an understandable pattern.</p>



<a name="214080940"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214080940" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Pankaj Ratan Lal <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214080940">(Oct 21 2020 at 16:57)</a>:</h4>
<p>I agree  that sooner one comes across lifetimes, the better. <br>
I think that may be I have an answer to my question. Take for example traits. Function declarations in trait is a contract between caller and callee. The implementations are not available at the time of declaration of trait.  The compiler thus, must not look ahead into implementation to infer it (even if available)  but rather just keep the eliding rules at the declaration level itself and make the contract enforceable so that both the implementation and caller can do whats needed based on this.</p>



<a name="214098296"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214098296" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214098296">(Oct 21 2020 at 19:00)</a>:</h4>
<p><span class="user-mention silent" data-user-id="315436">Pankaj Ratan Lal</span> <a href="#narrow/stream/122651-general/topic/lifetimes/near/214073475">said</a>:</p>
<blockquote>
<p>My answer to this was - and I want to know if I am right in what I am thinking - A compiler would not like to infer the declaration by looking at the implementation. It would like to make sure that the declaration is complete in itself. Declaration is the contract and would stay like that between caller and callee. What I could not answer with this theory was that rust does infer many things (like types) by doing a look ahead on the code and then enforcing the type if wrongly used. Why doesn't it then look at the implementation and do the best possible thing for lifetimes.</p>
</blockquote>
<p>A huge part of this is that rust wants you to be able to make the body of the function just be <code>todo!()</code> initially, and doesn't want it to break callers when you change it from <code>todo!()</code> -- which of course puts no constraints on the lifetimes in the signatures -- to the actual implementation.</p>
<p>That's also a big help for debugging things.  If you temporarily change a method to just be <a href="https://dilbert.com/strip/2001-10-25"><code>return 9</code></a>, you don't want that to affect anything outside the method.</p>
<p>(This is also why you need to fully specify types at method boundaries, even though inside the method Rust is happy to infer them for you.)</p>



<a name="214112406"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214112406" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jake Goulding <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214112406">(Oct 21 2020 at 20:45)</a>:</h4>
<p><span class="user-mention" data-user-id="315436">@Pankaj Ratan Lal</span> see also <a href="https://stackoverflow.com/q/31609137/155423">https://stackoverflow.com/q/31609137/155423</a></p>



<a name="214127375"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/122651-general/topic/lifetimes/near/214127375" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Pankaj Ratan Lal <a href="https://rust-lang.github.io/zulip_archive/stream/122651-general/topic/lifetimes.html#214127375">(Oct 21 2020 at 23:28)</a>:</h4>
<p>Great, thanks everyone. It all falls in place now.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>